NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/761

Internet Message Format | 1996-08-06 | 4.3 KB

Path: solon.com!not-for-mail
From: [e-mail] (Heiner Marxen)
Newsgroups: comp.std.c,comp.lang.c.moderated
Subject: Re: printf() format extensions - looking for beta testers...
Date: 18 Apr 1996 07:36:26 -0500
Organization: Dr. Brunthaler IITech GmbH, Germany
Sender: [e-mail]
Approved: [e-mail]
Message-ID: <4l5d0a$[e-mail]>
References: <4kgljv$[e-mail]> <4klicn$[e-mail]> <4kr78t$[e-mail]>
NNTP-Posting-Host: solutions.solon.com

In article <4kr78t$[e-mail]>,
Casper H.S. Dik - Network Security Engineer <[e-mail]> wrote:
>Ari Lukumies <[e-mail]> writes:
>> >                 format('!', bangcvt);
>> >
>> >                 /* do something which can generate an error */
>> >                 fprintf(stderr, "%s: %!\n", "open failed");
>> >         }
>
>>Given the above, how about calls like (well, not a pretty one, but you get
>>the idea...):
>
>>    fprintf(stderr, "%-*.2!", something);
>
>Yes, it seems that the format call back function (bangcvt) should take
>a number of flags (leading 0/- found, precision, maximum width) and
>a generic way to make the user defined format specifier output characters,
>as it can be called from functions like "snprintf", which limit the output.
>Passing a buffer to but the output in doesn't strike me as sufficient;
>if "bangcvt" can have unlimited output, it must be possible for the
>mechanism to cater for that.

All of this (and more) has been done, already.  I posted the "prf" package
to "alt.sources" in December 1993.  An extract from the README is below.

>And, of course, you want a input conversion as well :-)

True, but that is missing in "prf", too.  :-(

>So instead of:
>
>> >         int bangcvt(va_list *ap, char *s, int len, fmtspec *f) {
>
>You'd get something more like:
>
>    bangcvt (va_list *ap, int flags, int width, int precision,
>    char fmt, int (*putit)(char c, void *output), void *output)
>
>(Where you call "putit" for each character of output with *output
>as magic for the call back)

In "prf" there are two structs, one to describe the conversion specification
(from parsing the format string), and the other to describe the destination
of the output.  To call a function for every single character is just
one of the alternatives.  Others destinations are a simple FILE* or a limited
memory buffer.  The above now looks like:

    bangcvt (PrfDest* dp, PrfSpec* sp, va_list* ap)

The following is an extract of the README for the "prf" package:

|This is the first public release of the ``prf'' library, an extended
|and user programmable printf clone.
|
|For a description of function and interface see the manual page (prf.3x),
|e.g. with "nroff -man prf.3x | col | more -s".  A manual page output
|stripped down to plain ASCII can be found in "prf.3x.raw".
|
|In very short terms: what is this library good for?
|- After initializing the prf library with e.g. "stdprf();fltprf();extprf();",
|  you can call prf() instead of printf(), sprf() instead of sprintf,
|  and fprf() instead of fprintf(), and should get the same output.
|- You can use more/better conversions (e.g. prf("%b", 5) yields "101").
|- You can write new conversion functions and bind them to, say, "%z".
|- You can use other interface functions to have the output (format string
|  with embedded conversions) go into whatever destination you want it.
|
|The intent of the copyright notice in the sources and the file COPYRIGHT
|is to avoid legal problems and prevent others from claiming to be the author.
|No further restrictions are intended.
    [snip]
|At the time the prf library were written, I had no ANSI C available.
|Hence, it is all plain K&R C.  [snip]
|
|As far as possible and meaningful the prf library is consistent
|with ``printf'' as described in SVID and BSD 4.3 printf(1) manual page.
|As those descriptions are not at all complete, different behaviour
|of printf and prf in some details should be expected.
    [rest omitted]

The major drawback of the package seems to be that it is old K&R.
It definitely should be redone in ANSI-C.  There are also some
features still missing (e.g. flushing an arbitrary destination, or
installing format call back functions just by loading).

All in all, I have found "prf" inspiring and quite useful for years.
--
Heiner Marxen            [e-mail]